1. Field of the Invention
Embodiments relate to methods of conveying a location information representing a physical location of a communication device from the communication device to another communication device. Embodiments further relate to a computer program product for executing such a method and to the communication device for conveying the location information.
2. Background of the Related Art
A location information provided in an element of a device such as a communication device, e.g a mobile or an IP phone, represents the physical location of the device. This location information may be used by emergency services as NG911 (Next Generation 9-1-1) or NG112 (Next Generation 1-1-2) to locate the device that initiated an emergency communication request. Such a location information may be expressed as a civic location, e.g. a postal address, and/or as geospatial coordinates, e.g. a map location. The physical location of the device is required in order for the telephony server to locate a suitable emergency services number to be used to place the call (routing). This number is obtained by interrogating a remote Location to Service Translation server (LoST-server). This interrogation may be hampered by issues with connecting to the LoST-server, e.g. the LoST-server or the network connection of the LoST-server may be down. The standardization for NG911/NG112 requires the calling device in the form of a SIP endpoint                to convey the actual physical location during an emergency call. Updates have to be conveyed via a SIP INVITE or SIP UPDATE request,        to contact a mapping service based on the latest location information in order to obtain routing information during start-up and immediately before the emergency call set-up,        to validate the latest location information to ensure that the provided physical location is a valid and existing civic address or map location during start-up and immediately before the emergency call set-up. While obtaining the routing information is done via the LoST-server, validation is done via a Location Validation Function server (LVF-server) wherein the obtaining of the routing information and the validating of the latest location information may be done by the mapping service comprising the LoST-server and the LVF-server. If the SIP endpoint fails to contact the mapping service in time before an emergency call, the SIP endpoint must use cached data.        
In case of network environments, where a SIP endpoint contacts the mapping service via a SIP-server, the SIP-server contacts the mapping service on behalf of the registered SIP endpoint. If the SIP-server obtains the latest location information during the emergency call via a SIP INVITE or a SIP UPDATE request and fails to contact the mapping service for any reason, missing information might be the result. Additionally, if the SIP-server contacts the mapping service, but the location validation fails during the emergency call, the routing decisions may be based on a wrong, mistyped or incomplete civic address or map location. Updating the location information cached by the SIP-server by conveying the physical location of the SIP endpoint to the SIP-server periodically to keep the SIP-server updated before an emergency call is set up, however, has disadvantages: the physical location of a SIP endpoint or any other communication device is generally regarded to be sensitive information that should not be proliferated. Furthermore, there is an increased processor load involved by the SIP endpoint or the communication device periodically acquiring and sending location information. The sending of the location information from the SIP endpoint to the SIP-server is associated with an additional signaling load on the network used by the SIP endpoint in order to convey the physical location information to the SIP-server. Also, the SIP-server has to process and cache the location information provided by the SIP endpoint although this location information may not be used in an emergency call and therefore be outdated recently after being received from the SIP endpoint. Thus processing and memory resources of the SIP-server are reserved and allocated to location information periodically sent by the SIP endpoint even in cases where this location information will never be used in an emergency or other call. The conflict of having updated location information available while avoiding to reserve processing, network, and memory resources due to transmitting and storing location information potentially not used, may occur for any location-based service with or without a time critical aspect to obtaining location information relating to the current physical location of a device.
Existing standards advocate the use of a SIP INVITE request or a SIP UPDATE request to convey a changed physical location of a SIP endpoint. However, the use of the SIP INVITE request is only appropriate if the physical location was changed whilst in a call since generating a new call by using another SIP INVITE request may lead to interactions which block further calls based on policies, resources or priorities. Using the SIP UPDATE request to indicate a changed physical location prior to call establishment means that the SIP endpoint must support conveying the location information in an additional SIP message type. This may lead to inefficiency and maintenance problems. Another call independent mechanism for conveying a changed physical location has been standardized in RFC6447 (RFC: Request For Comments) by using a SIP Event Package. This mechanism requires additional support for the Event Package by both, the SIP-server and the SIP endpoint. Additionally, RFC6447 is designed to dereference location information for a specific target from a central server.